I want to stop talking about handover

Hi everyone.

In anticipation of doing this lightning talk, I've been hovering over this sort of resolution, which is that I want to stop talking about handover.

But I'm afraid that's a lie because I actually talk about and do handovers all the time, it feels like.

My name is Emma.

I'm an interaction designer at a company called TPX Impact and it's a design consultancy.

My experience has primarily been designing services for government departments.

They've typically been digital services, but they don't have to be.

And a big part of my job is doing design to developer handovers.

The prep for, doing, completing and yeah, talking about handover.

But when it comes to project planning and I'm thinking of things like sprint plans, roadmaps, project plans, I'm usually the person in the team who gets to review and feed into them.

I'm not the person typically creating their first iteration.

And so I tend to see quite a lot of plans that one way or another look a little bit like this.

Now, if I'm lucky, that dark grey row in the middle for handover is at least one week of a two week sprint.

But it's not uncommon for someone to have intended that to mean a single day.

Worse, it's meant to refer to a single handover meeting happening on that day.

And after that handover, I as the designer, I'm onto the next set of tasks like designing the next feature because handover is done, wrapped up with a bow and it's now the developer's problem.

And that's where in that sprint planning or review meeting, I'm getting a bit twitchy because handover is very, very rarely a single meeting from my experience.

It might be because the author of this sprint plan actually means sign off day.

So in some services that I've worked on, I have to get sign off from, say, a product or a service owner, maybe even both if the service has both of those roles on the team.

It might be deadline day, as in the day that I as the designer will stop my twiddling and tweaking of the design in anticipation of handing over.

But in my experience, handover is a bit of a process and I don't tend to think of it as something that has an exact start and end date, let alone a single day.

So when I see these project plans, I might be a bit nervous that handover and its process has been misinterpreted or more concerningly underestimated.

I also tend to notice that handover sits under my responsibility at max under the row of the design team's responsibility.

And I have something of an issue with that too.

Surprise, surprise.

You're kind of listening to me complaining at the start of this because handover I don't think of as a single person's responsibility.

If we're in sprint planning, we're kind of talking about team time and capacity, right?

So the developer or developers are kind of a crucial half of that equation as the recipient of my design handover.

And sure, I want to be part of shaping whatever handover in that project and team means, but not as the only person who's the decision maker or even the only person that we're acknowledging is spending time on this.

Handover has come to mean to me a few things.

Firstly, it's the artefacts that we collectively decide and agree are the single source of truth for the devs to work from.

I happen to design quite a bit in code first and it's pretty common that I am making coded prototypes as my design artefacts to demonstrate the intended behaviour and features of the service that we're designing.

But I have worked with developers who only want to work from screenshots in JIRA as their reference for what they're building.

And that's okay.

The prototypes I have made are actually usually for the purpose of bringing the future product or service to life for the users in our user research.

And that doesn't mean that the developers have to use the same thing.

It's also the back and forth on Slack between me and the developers or wherever the communication is taking place.

And I'm talking before, during, after.

The questions, the compromises, the check-ins, and all of that does take time.

It takes energy, it takes concentration, it takes having developed a good enough relationship where the developers feel like they can come back to me with those questions.

And yes, I have to admit, it might mean a sign-off process.

Like I said, I haven't found it uncommon that I have to get sign-off on my designs from the product owner ahead of doing any real handover work with the developers.

So there's an immediate dependency there, but if that takes longer, it might impact, or probably will impact, how long handover might go on for.

And on that note, it's the mad scramble when plans change.

Maybe the build of the first feature took longer than we originally thought.

So the four weeks we thought we had for this next feature coming along has turned into one.

Or maybe someone like the product owner has changed their mind.

They've reversed a decision they made on my designs ahead of the handover, and yet they're also not about to change the launch date.

So now the developer and I are descoping and re-scoping.

We are trying to figure out what we can keep from the original designs or journey.

We are trying to figure out what we can change on the fly, and what we might have to toss out and start again on.

And finally, I believe that handover might include letting things go.

It's about knowing when you have to stand your ground, because that change might negatively impact your users, that shortcut that you don't want to take.

But sometimes you have to compromise, and somebody has to draw the short straw.

So for me as a designer, it might mean that the feature gets built with a stripped back design and functionality at the launch, and the rest will have to come later.

And all these things are just things that I've picked up on as what I think of as like the skeleton of handover.

It's by no means a comprehensive list, right?

But I think I've been realising that that's what I want to be talking about more.

The people around us, and I'm thinking particularly those who aren't designers, who aren't developers, react based on how we phrase and communicate things.

And they're typically the ones, at least in my line of work, who are the ones making that first draft of the project plan, the sprint plan, and so on.

So in the same way that I have had someone genuinely ask what the difference is between the coded prototypes that I make with HTML, CSS, maybe like three lines of JavaScript, compared to the front end and back end service that the developers are building, because, well, they look the same, I have had people get twitchy when it sounds like handover of a feature is still going on.

Maybe I mention in stand-up that I'm talking to the developer later to go through XYZ, and there's this sort of panic like, "What?

But you're supposed to be done with that.

That was ages ago.

Why are you still on that?"

And I want to be clear, I don't see that as a failure on those people.

Their questions are just a symptom of how handover, of how that prototype has been interpreted.

So yeah, I will probably still talk about handover, forgive my earlier clickbait title, you can tell me off in the pub later, as Dave has been mentioning, but I do want to try and pinpoint how I can bring those other team members closer into what handover means in practice.

So I want to be more open about what handover is, like those five things I ran through with you of what I typically have found it includes, but being more open above all about what the developers and I might have decided, the what, the how, the why.

I want to be more honest about the time that it can take.

So being more deliberate in explaining where I'm actually spending my project time.

For the handover itself, yeah, sure, but everything else around it, right?

The new things to design for, the research to plan for, and so on, so that we can acknowledge, particularly in sprint planning, right, where and when I expect my teammates to be involved, so that we're thinking of the team capacity for that sprint or that phase of work.

And maybe that means that I have to suck it up, that I'm not always going to get, at least in that first iteration, the sprint plan that accounts for handover in the way that I hope it would.

But I'd like to think that doing some of these things, I might eventually end up with something that's a bit more like this, and it's one where in particular, both the developer and I have at least been able to shape that middle row of handover together as equal contributors.

Above all, I want to make it clear that if we're still talking about handover day, and they're meaning that it's the first time a developer is even seeing the designs, then we've probably already failed.

Maybe we're still meaning deadline day, that could be okay, but handover itself probably started quite a while before that day arrives.

And at this point, I'm actually going to throw it over to you all to ask if any of what I've been talking about is ringing a bell, maybe in like a different context, right?

Like the time it takes to download from a colleague who's leaving the company, or they're going on holiday for a while, and you're now in charge of the project.

Maybe you are on the other side, you are typically receiving a handover from the designer.

If any of you have been listening to this, and you thought you have a similar clickbait title for me in return, Emma, the one thing you need to solve this whole problem, and you'll never worry about it ever again, answer is on a postcard, please.

I would love to know the answer, come talk to me.

But with that, I'm going to end there and leave you with a very simple thank you for listening.